mptcp: ADD_ADDR are now sent sooner #34
Conversation
| @@ -16,9 +16,14 @@ | |||
| +0.01 < . 1:1(0) ack 1 win 257 <mpcapable v1 flags[flag_h] key[ckey=2,skey]> | |||
| +0 accept(3, ..., ...) = 4 | |||
|
|
|||
| // ADD_ADDR is sent directly (>= 5.12), not after first data (< 5.12) | |||
| +0 > . 1:1(0) ack 1 <add_address addr[saddr] hmac=auto,dss dack4=1 ssn=1 dll=0 nocs> | |||
| // TODO: support injecting ADD_ADDR echo | |||
There was a problem hiding this comment.
Linked to multipath-tcp/mptcp_net-next#142
(same for the others)
|
@geliangtang : may you confirm that the new behaviour is the expected one please? :) |
|
@matttbe Sorry Matt, I don't know what dose the dack8 mean. Does it mean ack64 in DSS? I found these lines in my kernel log: [ 55.888996] MPTCP: send ack for add_addr So we use ack64 in DSS indeed. |
|
Hi @geliangtang
Oh yes sorry I should have clarified that. Yes it means ack64.
Thank you for having looked! Before sending the ACK with the ADD_ADDR, we didn't receive any 64bit DSN. In theory, we should only send a ACK64 if we got a 64bit DSN before. See: multipath-tcp/mptcp_net-next@a0c1d0e |
matttbe
force-pushed
the
issue-144-add_addr-sooner
branch
from
8658730
to
c102506
Compare
not sure if this problem just happens after reception of ADD_ADDR. But I think we can merge this commit and then eventually change scripts again once the kernel behavior is improved. @geliangtang / @matttbe, do you think that issue multipath-tcp/mptcp_net-next#139 could also fix issue multipath-tcp/mptcp_net-next#112 ? |
A recent modification of the kernel changes the way ADD_ADDR are sent. See: multipath-tcp/mptcp_net-next#139 In consequences, we have to adapt our tests to have these ADD_ADDR sent earlier, ASAP in fact. We now make sure ADD_ADDR and ADD_ADDR echo are properly sent before injecting MP_JOIN SYN and SYN+ACK or sending data. Closes: multipath-tcp/mptcp_net-next#144 Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
matttbe
force-pushed
the
issue-144-add_addr-sooner
branch
from
c102506
to
5b9c921
Compare
@dcaratti : Sounds good to me! I just found the answer to my question about the dack8, see above :)
When re-reading the description of your issue, it could be linked but I don't think I saw this behaviour on my CI. Maybe something else needs to be adapted on your kernel? |
I will try that reverting locally multipath-tcp/mptcp_net-next@4a41f453be, and see if I see the selftest 13 failing |
A recent modification of the kernel changes the way ADD_ADDR are sent.
See: multipath-tcp/mptcp_net-next#139
In consequences, we have to adapt our tests to have these ADD_ADDR sent
earlier, ASAP in fact. We now make sure ADD_ADDR and ADD_ADDR echo are
properly sent before injecting MP_JOIN SYN and SYN+ACK or sending data.
Closes: multipath-tcp/mptcp_net-next#144
Signed-off-by: Matthieu Baerts matthieu.baerts@tessares.net